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IDENTIFICATION OF MISSING PROPERTIES IN MODEL CHECKING 



FIELD OF THE INVENTION 



The present invention relates generally to design 
automation and verification, and specifically to hardware 
5 verification of integrated circuit design. 



Hardware verification is currently the bottleneck 
and the most expensive task in the design of a 
semiconductor integrated circuit. Model checking is a 
10 method of formal verification that is gaining in 
popularity for this purpose. The method is described 
generally by Clarke et al. in Model Checking (MIT Press, 
1999), which is incorporated herein by reference. 



15 a verification engineer reads the definition and 
functional specifications of the device and then, based 
on this information, writes a set of properties {(j)} (also 
known as a specification) that the design is expected to 



20 specification language for expressing temporal logic 
relationships between the inputs and outputs of the 
device. Such languages are commonly based on Computation 
Tree Logic (CTL) . A hardware model M (also known as an 
implementation) of the design, which is typically written 

25 in a hardware description language, such as VHDL or 
Verilog, is then tested to ascertain that the model 
satisfies all of the properties in the set, i.e., that 
Mt=()), under all possible input sequences. Such testing is 
a form of reachability analysis. 



BACKGROUND OF THE INVENTION 



To perform model checking of the design of a device, 



fulfill. 



The properties are written in a suitable 
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Model checking is preferably carried out 
automatically by a symbolic model checking program, such 
as SMV, as described, for example, by McMillan in 
Symbolic Model Checking (Kluwer Academic Publishers, 
1993), which is incorporated herein by reference. A 
number of practical model checking tools are available, 
among them RuleBase, developed by IBM, which is described 
by Beer et al. in "RuleBase: an Industry-Oriented Formal 
Verification Tool," in Proceedings of the Design 
Automation Conference DAC 9 6 (Las Vegas, Nevada, 1995), 
which is incorporated herein by reference. 

As hardware devices grow larger and more complex, 
the set of properties needed for model checking becomes 
unwieldy. The verification engineer has no systematic 
way to be sure of whether the property set is complete, 
in the sense of covering all possible states and 
transitions that may occur in the model. If the property 
set is incomplete, a bug in the design may go undetected. 
The engineer may therefore continue to add more and more 
properties indefinitely, never knowing whether the set is 
yet sufficient or not. 

Coverage metrics have been applied in various fields 
of simulation-based verification in order to measure and 
improve the completeness with which a given simulation 
tool represents the actual behavior of a target system. 
An application of such a metric to model checking is 
described by Hoskote et al. in "Coverage Estimation for 
Symbolic Model Checking," in Proceedings of the Design 
Automation Conference DAC 99 (IEEE Computer Society 
Press, 1999), which is incorporated herein by reference. 
The authors present a method for estimating whether a set 
of properties is sufficient to cover all possible states 
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of a model. They note, however, that their method cannot 
point out functionality that may be missing in the model, 
nor can it ensure that all possible paths between the 
states are covered. They indicate that "path coverage 
would be an ideal coverage metric because it can provide 
coverage of actual executions of the circuit over time." 
The authors consider that by comparison with state 
coverage, "path coverage is a much more intractable 
problem. " 
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SUMMARY OF THE INVENTION 

It is an object of some aspects of the present 
invention to provide improved methods and systems for 
design verification. 
5 It is a further object of some aspects of the 

present invention to provide improved methods and metrics 
for analyzing the coverage of a set of properties used in 
model checking, and in particular to provide methods for 
analyzing path coverage. 

10 In preferred embodiments of the present invention, a 

specification, consisting of properties, is generated to 
verify a given implementation model of a target system, 
and a tableau is constructed corresponding to the 
properties. Such a tableau is defined as a finite state 

15 machine that satisfies all of the properties in the 
specification. The states and transitions of the tableau 
are compared to those of the model to ascertain that 
there is full correspondence between the possible states 
and transitions of the model and those of the tableau. 

20 To the extent that there are no substantive differences, 
it is concluded that the set of properties fully 
specifies the model. 

In some preferred embodiments of the present 
invention, the tableau is compared to the model by 

25 inputting the tableau to a model checking program, such 
as SMV, along with the given model. If for every 
possible combination of inputs, the tableau gives exactly 
the same set of outputs as the model, then the 
specification of the properties is complete. On the 

30 other hand, if a difference occurs for some input, it 
means that the specified properties are insufficient 
and/or that there is an error in the model. The fact 
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that the outputs of the tableau exactly correspond to 
those of the model indicates that for every reachable 
state of the tableau, there is a corresponding state in 
the model, and for every possible transition in the 
5 tableau, there is a corresponding transition between the 
corresponding states in the model. It also means that 
there are no excess transitions or spurious initial 
conditions in the tableau that would allow transitions to 
be made among states in a way that would not be possible 

10 in the model. 

The methods of the present invention thus inform the 
user when the specification of properties is complete or, 
alternatively, provide an indication as to where there 
may be flaws in the correspondence between the 

15 specification and the model. Such flaws typically point 
either to a state or transition in the tableau that is 
not implemented in the model, thus warning either that 
the specification does not adequately constrain the 
model, or that the model has failed to implement a 

20 meaningful state or transition of the target system. By 
comparison, the method of Hoskote et al . is limited to 
finding an estimation of state coverage, and not 
transitions or exact state coverage, and therefore cannot 
provide a conclusive indication that the set of 

25 properties is complete. 

There is therefore provided, in accordance with a 
preferred embodiment of the present invention, a method 
for verification, including: 

providing an implementation model, which defines 

30 model states of a target system and model transitions 
between the model states; 
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providing a specification of the target system, 
including properties that the system is expected to obey; 

creating a tableau from the specification, the 
tableau defining tableau states with tableau transitions 
between the tableau states in accordance with the 
properties; and 

comparing the tableau transitions to the model 
transitions to determine whether a discrepancy exists 
therebetween . 

In a preferred embodiment, creating the tableau 
includes defining a finite state machine using a hardware 
description language, wherein the implementation model 
has model inputs and outputs, and wherein defining the 
finite state machine includes describing a virtual device 
having inputs and outputs corresponding to the model 
inputs and outputs of the implementation model. 
Preferably, comparing the transitions includes performing 
a reachability analysis using both the implementation 
model and the tableau while providing identical inputs to 
the inputs of both the implementation model and the 
tableau, and verifying that the outputs are always 
identical. Most preferably, performing the reachability 
analysis includes comparing the model and the tableau 
automatically using a model checker and providing 
evidence of a tableau transition that is not implemented 
in the model. 

In another preferred embodiment, comparing the 
tableau transitions includes associating model 
transitions with corresponding tableau transitions, 
wherein associating the transitions includes defining a 
reachable simulation preorder relating the model and the 
tableau. Preferably, associating the transitions 
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includes finding a tableau transition that is not 
implemented in the model and, most preferably, deriving 
an indication, based on the unimplemented transition, 
that the specification is not complete with respect to 
5 the model. Alternatively or additionally, finding the 
tableau transition that is not implemented in the model 
includes deriving an indication, based on the 
unimplemented transition, that a transition of the target 
system is missing in the model. 

10 Preferably, the method includes associating model 

states with corresponding tableau states. Further 
preferably, associating the model states with the 
corresponding tableau states includes finding a tableau 
state that is not implemented in the model and deriving 

15 an indication, based on the unimplemented state, that the 
specification is not complete with respect to the model. 
Alternatively or additionally, finding the tableau state 
that is not implemented in the model includes deriving an 
indication, based on the unimplemented state, that a 

20 state of the target system is missing in the model. 
Further alternatively or additionally, associating the 
model states with the corresponding tableau states 
includes finding multiple model states corresponding to a 
single tableau state. 

25 Preferably, creating the tableau includes creating a 

reduced tableau from which one or more redundant states 
have been eliminated. 

Further preferably, comparing the transitions 
includes verifying that the specification is a complete 

30 and correct description of the implementation model 
responsive to the comparison. 
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There is also provided, in accordance with a 
preferred embodiment of the present invention, a 
verification processor, which is configured to receive an 
implementation model, defining model states of a target 
system and model transitions between the model states, 
and to receive a specification of the target system, 
including properties that the system is expected to obey, 
and which is operative to create a tableau from the 
specification, the tableau defining tableau states with 
tableau transitions between the tableau states in 
accordance with the properties, and to compare the 
tableau transitions to the model transitions to determine 
whether a discrepancy exists therebetween. Preferably, 
the processor is operative to perform model checking of 
the implementation model. 

There is further provided, in accordance with a 
preferred embodiment of the present invention, a computer 
software product for verification of a specification of a 
target system, which specification includes properties 
that the system is expected to obey, by comparison with 
an implementati on model, which defines model states of 
the target system and model transitions between the model 
states, the product including a computer-readable medium 
having computer program instructions recorded therein, 
which instructions, when read by a computer, cause the 
computer to create a tableau from the specification, the 
tableau defining tableau states with tableau transitions 
between the tableau states in accordance with the 
properties, and to compare the tableau transitions to the 
model transitions to determine whether a discrepancy 
exists therebetween. 
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Preferably, the program instructions cause the 
computer to compare the tableau with the model by running 
a reachability analysis using both the implementation 
model and the tableau while providing identical inputs to 
5 the inputs of both the implementation model and the 
tableau, and verifying that the outputs are always 
identical. Most preferably, the reachability analysis is 
performed using an automatic model checker, and the 
instructions cause the computer to verify that the 

10 specification is a complete description of the 
implementation model. 

There is additionally provided, in accordance with a 
preferred embodiment of the present invention, a method 
for verification, including: 

15 providing an implementation model, which defines 

model states of a target system and model transitions 
between the model states; 

providing a specification of the target system, 
including properties that the system is expected to obey; 

20 creating a tableau from the specification, the 

tableau defining tableau states with tableau transitions 
between the tableau states in accordance with the 
properties; and 

comparing the model and the tableau by inputting the 

25 model and the tableau to an automatic model checking 
program. 

Preferably, comparing the model and the tableau 
includes providing evidence of a transition or state in 
the tableau that is not implemented in the model, most 
30 preferably in the form of a counter-example indicative of 
the unimplemented transition or state. 
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There is moreover provided, in accordance with a 
preferred embodiment of the present invention, model 
checking apparatus, which is configured to receive an 
implementation model, defining model states of a target 
5 system and model transitions between the model states, 
and to receive a specification of the target system, 
including properties that the system is expected to obey, 
and which is operative to create a tableau from the 
specification, the tableau defining tableau states with 

10 tableau transitions between the tableau states in 
accordance with the properties, and to compare the 
tableau to the model by inputting the model and the 
tableau to an automatic model checking program. 

There is furthermore provided, in accordance with a 

15 preferred embodiment of the present invention, a computer 
software product for verification of a specification of a 
target system, which specification includes properties 
that the system is expected to obey, by comparison with 
an implementation model, which defines model states of 

20 the target system and model transitions between the model 
states, the product including a computer-readable medium 
having computer program instructions recorded therein, 
which instructions, when read by a computer, cause the 
computer to create a tableau from the specification, the 

25 tableau defining tableau states with tableau transitions 
between the tableau states in accordance with the 
properties, and to compare the tableau to the model by 
inputting the model and the tableau to an automatic model 
checking program. 

30 The present invention will be more fully understood 

from the following detailed description of the preferred 
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embodiments thereof, taken together with the drawings in 
which : 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic pictorial illustration showing 
5 a system for model checking, in accordance with a 
preferred embodiment of the present invention; 

Fig. 2 is a block diagram that schematically 
illustrates an implementation model used in model 
checking and a corresponding tableau of properties, in 
10 accordance with a preferred embodiment of the present 
invention; 

Fig. 3 is a state diagram that schematically 
illustrates a finite state machine corresponding to the 
tableau of Fig. 2, in accordance with a preferred 
15 embodiment of the present invention; 

Fig. 4 is a flow chart that schematically 
illustrates a method for verifying a set of properties 
generated for the purpose of model checking, in 
accordance with a preferred embodiment of the present 
20 invention; and 

Fig. 5 is a flow chart that schematically 
illustrates another method for verifying a set of 
properties generated for the purpose of model checking, 
in accordance with a preferred embodiment of the present 
25 invention. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Fig. 1 is a scheinatic pictorial illustration of a 
system 20 for model checking, in accordance with a 
preferred embodiment of the present invention. System 20 
typically comprises a verification processor 22, 
typically a general-purpose computer workstation running 
suitable model checking software, such as the 
above-mentioned IBM RuleBase, under the control of a 
verification engineer 24. The system receives a hardware 
implementation model 26 of a target system or device 30 
in development. Engineer 24 prepares a specification of 
properties 28, for use in model checking of model 26. 
The completeness and correctness of the specification are 
verified by system 20 using methods described in detail 
hereinbelow. 

Reference is now made to Fig. 2, which is a block 
diagram representing a model of a target hardware device 
40, in this case a simple two-port synchronous arbiter, 
used hereinbelow to exemplify a method for verifying 
property set 28, in accordance with a preferred 
embodiment of the present invention. Device 4 0 has two 
request inputs 42, labeled REQO and REQl, and two 
acknowledge outputs 44, ACKO and ACKl . The assertion of 
ACKi is a response to the assertion of REQi . Initially, 
both outputs of the arbiter are inactive. At any time, 
at most one acknowledge output may be active. The 
arbiter grants one of the active requests in the next 
cycle, and uses a round robin algorithm in case both 
request inputs are active. In the case of simultaneous 
assertion (i.e. both requests are asserted and were not 
asserted in the previous cycle), REQO has priority in the 
first simultaneous assertion occurrence. In any 
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subsequent occurrence of simultaneous assertion the 
priority rotates with respect to the previous occurrence. 

An implementation of device 40 in the SMV language 
is presented below in Table I: 



1 ) var 

2) reqO; reql ; 

3) assign 

4) init(ackO) 

5) init(ackl) 

6) init (robin) 

7) next(ackO) 



3) 



! reqO 



TABLE I 

ackO; ackl; robin : boolean; 

= 0; 
= 0; 
= 0; 

= case 
: 0; 



9) !reql 

10) !ackO&!ackl 



12) esac; 



13) 
14) 

15) 
16) 
17) 



next (ackl ) : = 
! reql 

! reqO 

! ackOs ! ackl 
1 



18) esac; 

19) next (robin) 



- No request results no 
ack 

: 1; - A single request 

:! robin; - Simultaneous requests 

assertions 
:!ackO; - Both requesting, toggle 

ack 



0; - No request results no 

ack 

1; - A single request 

robin; - Simultaneous assertion 
!ackl; - Both requesting, toggle 
ack 



=if reqO&reql& ! ackOS ! ackl then ! robin 
else robin endif; - Two 

simultaneous request 
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assertions 

From the functional specification of arbiter 40 
given above, the following temporal formulas are derived 
5 that describe the properties of the device: 

1. The initial state is -lackO a -lackl. 

2. At all times, mutual exclusion holds, i.e., -lackO v 
-lackl (property (j)l) . 

3. At all times one of the following properties should 
10 hold: 

a) No requests followed by no acknowledge (property 
^2) . 

b) A single request (when the other request is not 
active) is served in the following cycle (properties 

15 (j)3 and ^A) . 

c) A request active while the alternate channel is 
being served will be served in the following cycle 
(properties (|)5 and (j)6) . 

d) When a cycle with no active request is followed by 
20 a cycle with two active requests, the result will be 

as follows - 

• The first such occurrence will result in 
acknowledgment to channel 0 ((|)0) . 

• Each subsequent occurrence will result in 
25 acknowledgment of the channel that was not 

acknowledged in the previous occurrence ((j)? and 
(t>8) . 

The behavior of the arbiter under these conditions 
(no active request followed by two active requests) 
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is governed by the non-observable variable "robin, " 
as defined in Table I. 
The above formulas correspond to the properties (j)0, 
(j)l, (|)8 listed symbolically below in Table II, which are 
5 a complete specification of arbiter 40 written in the 
form of a safety formula v|/ in Universal Computation Tree 
Logic (known as ACTL) . ACTL is a branching-time temporal 
logic. It is described in detail by Grumberg et al. in 
"Model Checking and Modular Verification," in ACM 
10 Transactions on Programming Languages and Systems 16(3) 
(1994), pp. 843-871, which is incorporated herein by 
reference. As the variable "robin" is not observable, it 
does not appear explicitly in the properties in Table II. 

TABLE II 

15 v|/ = -,ackO A -lacklA 

A[(-,reqO v -,reql v ackO v ackl)W 

(reqO a reql a -,ackO a -,ackl a AXackO)]A - 

AG( 





(-lackO V -lackl) a 


- ^1 


20 


(^reqO a ^reql AX(-,ackO A^ackl) ) a 


- ^2 




(reqO a -,reql AX ackO) a 


- ^3 




(-,reqO A reql AX ackl) a 


- (j)4 




(reql a ackO AX ackl) a 


- h 




(reqO a ackl AX ackO) a 


- (1)6 


25 


(reqO a reql A-iackO A-iackl -> AX(ackO - 
A[ (-ireqO v-ireql v ackO v ackl)W 





(reqO a reql A-iackO A^ackl a AXackl)]))A -^j 
(reqO a reql A-iackO A-iackl -> AX (ackl 
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A[ (— ireqO v— ireql v ackO v ackl)W 
(reqO a reql A-iackO A-iackl a AXackO)])) ) -^s 

This representation uses the temporal operators X ("next 
5 state"), W ("weak until," i.e., remains true until), and 
G ("globally") , along with the quantifier A ("for all 
paths") . It is noted that AGkj) = A[(t)Wfalse] . 

Fig. 3 is a state diagram that schematically 
illustrates a tableau 50, or state machine, corresponding 

10 to the properties of the safety formula in Table II, in 
accordance with a preferred embodiment of the present 
invention. The tableau is preferably a "reduced 

tableau," as defined in Appendix A, which is most 
preferably constructed automatically, using a computer 

15 program that receives the properties as its input and 
implements the tableau construction algorithm listed in 
the appendix. The tableau is used, as described further 
hereinbelow, to verify that the properties completely 
cover the states and transitions of the device model 

20 defined in Table I. 

Tableau 50 comprises six state groups 52, 54, 56, 
58, 60 and 62. Each of the groups includes a number of 
states 64 that correspond to a particular output 
condition of device 40, i.e., in groups 52 and 60, ackO 

25 is asserted; in groups 54 and 62, ackl is asserted; and 
in groups 56 and 58, neither output is asserted (!ack0 
!ackl). In state groups 52, 54 and 56, the 

non-observable variable robin = 0, whereas in groups 58, 
60 and 62, robin = 1. As indicated by an arrow 66, 

30 operation of device 40 begins in group 56, with !ackO, 
!ackl and robin = 0. Transitions from one state to 
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another depend on the choice of inputs, which are marked 
in each state 64. Thus, for example, when reql is 
asserted in state group 52, a transition is invoked to 
group 54, in which ackl is asserted. 
5 Tableau 50 is a sort of virtual device, 

corresponding to actual target device 40. Appendix B 
accordingly contains source code in VHDL representing a 
tableau similar to tableau 50 as a device model. In 
preferred embodiments of the present invention, this 

10 virtual device is tested to determine whether its states 
and transitions correspond exactly to those of the actual 
device, or equivalently whether the behavior of the 
virtual device under all possible combinations of input 
conditions is identical to that of the model of the 

15 actual device. If differences are found, they are then 
indicative either that the tableau (and hence the 
specified properties) are incomplete or that the model 
itself is incomplete. Methods and criteria for testing 
tableau 50 are described further hereinbelow. 

20 Fig. 4 is a flow chart that schematically 

illustrates a method for verifying a specification of 
model checking properties by comparing tableau 50 with 
device 40, in accordance with a preferred embodiment of 
the present invention. The method begins with 

25 preparation of the specification, such as the formula \\) 
listed in Table II, and checking the device model M to 
ensure that the model satisfies the specification, i.e., 
that M\=\\f. The specification is then used to construct 
the tableau. As shown in Fig. 2, tableau 50 as a virtual 

30 device model has virtual inputs 72 and outputs 74, 
corresponding respectively to inputs 42 and outputs 44 of 
implementation model 40 of the target device. For the 
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purpose of testing the tableau against the implementation 
model, the tableau inputs are labeled REQO_SPEC and 
REQ1_SPEC, and the tableau outputs are labeled similarly, 
ACKO_SPEC and ACK1_SPEC. 

These input and output labels are inserted in a 
representation of the tableau, preferably in the form of 
suitable program code, as listed in Appendix B. IBM 
RuleBase, as described hereinabove, is capable of 
translating the VHDL code in Appendix B into the SMV 
language used by model checkers. In the example shown in 
Appendix B, the model of device 40 is simplified, 
relative to the definition in Tables I and II, in that 
the non-observable variable "robin" is not used. 
Instead, ackO always receives priority when a state in 
which there is no active request is followed by two 
active requests. 

In order to test the tableau against the device 
model, a new model is created, combining the original 
implementation model and the virtual device model of the 
tableau. Inputs 72 of tableau 50 are tied to the 
corresponding inputs 42 of implementation model 40, so 
that the implementation model and the tableau model will 
receive the same input signals. The new, combined model 
is then input to an automatic model checking program, 
such as SMV. The model checker is asked to verify that 
the following properties regarding the combined model 
outputs are always true of the combined model: 

ACKO==ACKO_SPEC 
ACK1==ACK1 SPEC 
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Alternatively, in certain cases, the two outputs may be 
checked separately, rather than in a single pass of the 
model checker, using separate tableaux corresponding to 
subsets of the specification properties that influence 
the particular outputs. 

If the above-mentioned properties of the combined 
model outputs are confirmed, tableau 50 is assured of 
representing a complete and correct specification of 
device 40. If the tableau specification is not 

sufficiently detailed, then the tableau outputs ACKi_SPEC 
will not be as constrained as the model outputs ACKi, and 
there will be some combination of inputs under which 
ACKi_SPEC will have two possible values when ACKi can 
have only one. This outcome will generally lead engineer 
24 to conclude that an additional constraint is required, 
i.e., that a further property is needed in the 
specification. Typically, a suitable property is added 
and the specification is re-checked, repeating the steps 
described above. If now ACKi==ACKi_SPEC, then the 

specification can be considered complete and correct. 
Alternatively, it may turn out that evaluation of the 
model and specification in this manner will lead engineer 
24 to conclude that there is an error in the 
implementation model, such as a missing state or 
transition, which causes the outputs of the model and the 
tableau differ. It is a further advantage of automatic 
model checking programs that they provide evidence of 
such errors, in the form of "counter-examples," that 
assist the engineer in identifying and correcting the 
error . 

Fig. 5 is a flow chart that schematically 
illustrates another method for verifying a model checking 
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specification, in accordance with a preferred embodiment 
of the present invention. The method begins, like the 
method of Fig. 4, with preparation of a specification of 
model properties and model checking to determine that the 
model satisfies the specification. The specification is 
then used to create a corresponding tableau, which is 
evaluated against the device implementation model. The 
method of Fig. 5 differs from the method of Fig. 4 in the 
manner in which the tableau is evaluated, as described 
hereinbelow. Whereas the method of Fig. 4 is useful 
primarily in checking deterministic models, the method of 
Fig. 5 can be used for substantially any model, including 
non-deterministic models. 

In order to evaluate the tableau against the model, 
a simulation preorder, SIM, is calculated for the model 
and the tableau. SIM is a relation between the model M 
and the tableau T (SIM C M x T) containing pairs of 
states (Si,st) in M and T, respectively. SIM satisfies 
the following requirements: 

• For every initial state Soi of M, there is an 
initial state Sot of T, such that (soi,sot) belongs to 
SIM. 

• For every pair of states (Si,St) in SIM, state s± 
is characterized by the same set of atomic 
propositions as St (i.e., the same values of the 
variables ACKi and REQi in the example of device 
40) . 

• For every state-to-state transition from state Si, 
there is a corresponding transition for state St 
(although not necessarily a one-to-one 
correspondence) . 



IS999-035 



20 



35519S3 



Formally, an algorithm for the computation of SIM is 
presented in Table III, below, in pseudocode form. Here 
Si(Si) is the set of all values of states in M, and St(st) 
is the set of all values of states in T ((j)) . Ri(Si,Si') is 
the transition relation of M, and Rt{st,St') is the 
transition relation of T ((])). Li(Si) is a labeling 
function that computes the values of atomic propositions, 
AP, of a state si of M, while Lt(st) is a labeling 
function that computes the values of atomic propositions, 
AP, of a state St of T {^) . 

TABLE III 

Init: 

SIMo(si, St) := {(si, St) e Si X St 1 L^is^) = Lt(St)}; j := 0 
Repeat { 

SIMj+^ := {(si, St) I 

VSi' (iRi(si, Si') 3st' [Rtistr St') A SIM-jis^' , St'))) A SIMj{s„ St) 
j:=j+l 

} until SIMj=SIMj-i 
SIM:=SIMj 

Preferably, for efficient computation. Si, St, Ri, Rt, 
Li, Lt and SIMj are all represented as Ordered Binary 
Decision Diagrams (OBDDs) . This type of representation, 
using connected, directed, acyclic graphs, is known in 
the art of model checking. The use of OBDDs in this 
regard is described, for example, by McMillan in Symbolic 
Model Checking (Kluwer Academic Press, Norwell, 
Massachusetts, 1993) , which is incorporated herein by 
reference . 
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All of the operations shown in Table III are well 
known for OBDDs, except for the computation of SIMj+i. To 
state this computation in OBDD terms, we define the 
following OBDD operations: 

5 

compose(y, u) = 3x(a(x, y) a b(x, u)) 
compose _ odd(y, u) = 3x(a(y, x) a b(u, x) 

These two operations operate on two OBDDs, a and b, over 
10 three vectors of n variables, x, y and u. In these 
terms, the computation of SIMj+i is given by: 

SIM^+l(s^, St) := -^compose _ odd{Rj_{si, s^')' 

-ncompose _ odd(Et(^t' ^t')' SIMj(sj:' , s^')) ) a SIMj{sj., Sf-) 

15 Based on the simulation preorder SIM, a reachable 

simulation preorder for M and T, ReachSIM, is determined. 
T may contain paths by which a state s is reached from an 
initial state, which do not have corresponding 
permissible paths in M. ReachSIM £ SIM contains only 

20 pairs of states (Si,st) characterized in that states si 
and St are reached by corresponding paths n± and Ht from 
corresponding initial states. A path Ki = soi, sn, si, 
and a path 7Ct = sot, Sit, .-, st are considered to 
correspond if every pair of states (Si,St) along the paths 

25 belongs to SIM. Details of the computation of ReachSIM 
are presented in Table IV: 

TABLE IV 

Jnit; 
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ReachSIMQ := (Sqi x Sot) n SIM; j := 0 
Repea t { 

ReachSIMj+i := {(s^' , s^') I Bs^r St{ReachSIMj{s^, a R^is^, s^') a 
Rt(str St') a SIm{s±' r St')) } U ReachSIMj 
j := j+1 

5 } until ReachSIMj = ReachSIMj-i 
ReachSIM := ReachSIMj 

Here, too, if Si, St, Ri, Rt, Li, Lt and ReachSIMj are all 
OBDDs, then all of the operations in Table IV are well 
10 known, except for the computation of ReachSIMj+i, which is 
given in OBDD terms by: 

Reacts IMj+iis^r h) '•= {compose{compose(ReachSIMj{s;^, s^) 
Rii^f Si')) ' -Rtfe. 4')) A SJM(si' , St')) V ReachSIMjis^' , St') 

15 ReachSIM thus identifies a set of states in T having 

transitions that correspond to the actual transitions in 
M. There may yet be, however, states or transitions in T 
that do not have corresponding states or transitions in 
M, meaning that the specification does not constrain the 

20 implementation model tightly enough, so that one or more 
additional properties are needed. Such states and 
transitions are referred to herein as being 
''unimplemented. " There may likewise be states in T that 
correspond simultaneously to two or more states in M. 

25 Such discrepancies are detected using ReachSIM to 
evaluate the following criteria (preferably using OBDD 
operations), either serially or in parallel: 
• Unimplemented start states: 
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These are initial tableau states that have no 
corresponding initial states in the model (and 
therefore are absent from ReachSIM) . The existence 
of an unimplemented start state indicates either 
that the specification does not adequately constrain 
the start states, or that the model is lacking a 
required initial state. 

• Unimplemented states: 

The existence of a state anywhere in the tableau 
that is not included in ReachSIM indicates either 
that the specification is lacking in constraints or 
that a meaningful state of the device is not 
implemented in the model. 

• Unimplemented transitions: 

[s^, St) e ReachSIM, (s^, St') g ReachSIM, (s^, s^') g R^] ] 
These are transitions between states of the tableau 
for which there is no corresponding transition in 
the model. The states belong to ReachSIM, so that 
they have corresponding states in the model, which 
are reached by corresponding paths. The existence 
of an unimplemented transition indicates either that 
the specification is not tight enough or that a 
required transition, between reachable 

implementation states, was not implemented in the 
model. Assuming Si, Ri, Rt and ReachSIM are all 
OBDDs, the set of unimplemented transitions can be 
represented by the following equation: 
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nimplementedTransition{si-, s^') := compose{ 
compose{-nR^^{sj_, s^'), ReachSIM(sj_, s^)\ ReachSIM{si^' , s^')) a R^{s^, s^') 
• Many-to-one mapping: 
St e St I 3sii, ^21 e Si 

(sii, St) e ReachSm, (s2i, St) g ReachSIM, s^^ ^ S2i] 
In this case, there may be a tableau state to which 
5 multiple implementation states are mapped, i.e., a 

state s which is paired in ReachSIM with at least 
two different model states si' and Sj' . The 
existence of a many-to-one state indicates either 
that the specification is not sufficiently detailed, 
10 or that the implementation contains redundancies. 

If ReachSIM and the model states are OBDDs, the set 
of many-to-one states can be represented by: 

ManyToOnd^^) = 3v-^{ReachSIM{si, s^) a composei{si ^ S2) 
ReachSIM(s2, s^) 

15 

If the first three of these four criteria return 
empty results, then T is a complete specification of M. 
Any dissimilarity between the tableau and the 
implementation will result in a non-empty result. 

20 Preferably, the tableau T that is used in this method is 
a reduced tableau, as defined in Appendix A, since 
traditional (non-reduced) tableaux typically contain 
redundancies, which are removed in the reduced tableau. 
If the first three of the criteria above hold (i.e., 

25 return empty results) , T and M are bisimilar, and the 
fourth criterion is not necessary to establish the 
completeness of T. It may, however, indicate that there 
are redundancies in the implementation. 
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As noted hereinabove, verification of specification 
properties vis-a-vis the implementation model, using any 
of the methods described herein, is preferably carried 
out using software for this purpose running on processor 
5 22. Software for use in such verification is preferably 
supplied as component of a simulation and model checking 
software package. Alternatively, the software for 

tableau construction and verification is provided as an 
independent software package. In either case, the 

10 software may be conveyed to processor 22 in intangible 
form, over a network, for example, or on tangible media, 
such as CD-ROM. 

Although preferred embodiments are described 
hereinabove with reference to certain methods and 

15 languages used in model checking, it will be understood 
that the application of the present invention is not 
limited to any particular language or method of 
implementation. Those skilled in the art will appreciate 
that the principles of the present invention may 

20 similarly be used in other areas of verification, not 
only for electronic devices, but also in verification of 
other types of target systems, as well, for example, 
transportation systems or complex valve manifolds. It 
will thus be understood that the preferred embodiments 

25 described above are cited by way of example, and the full 
scope of the invention is limited only by the claims. 
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APPENDIX A 

1 Reduced Tableau for ACTL 

In this section we define a reduced tableau for the subset of ACTL safety 
formulas. We follow the definition of the reduced tableau for LTL presented 
in [3]. A tableau is a special form of a Kripke structure, consisting of states 
labeled with atomic propositions and transitions between the states. As is 
often the case with tableaux for temporal logics (e.g. [2. 1]). a state of the 
tableau consists of a set of formulas that are supposed to hold along all paths 
leaving the state. Unlike typical tableaux, however, the formulas in the states 
of the reduced tableau are interpreted over a three-valued domain. Thus, a 
state may include a formula or its negation, or none of the two. If the latter 
occurs, it reflects a "don't care'' situation, i.e.. the formula may be either 
true or false in the state. 

Similarly to [2]. we wish the reduced tableau for a formula ^ to satisfy 
<f). Furthermore, it should be greater by the simulation preorder [4] than 
any Kripke structure that satisfies ip. In order to achieve these goals we 
will adapt both definitions of \= and simulation preorder to be applicable 
to three-valued structures. Below we present the formal definitions of the 
tableau and of the adapted relations. 

Let AP^ be the set of atomic propositions in an ACTL formula 'tp . 

Definition 1.1 (sub-formulas) The set o/ sub-formulas of tp is defined 
recursively as follows : 

L sub{p) = {p} and sub{-^p) — {^p}, if p ^ AP^ 

2. sub{(fi) = {<f} U sub[gi) U sub{g2), if <f — gi A g2 or (p = gi^/ g2. 

3. sub{AXg{) = {AXg^} U sub{gi) 
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4. subiA[giWg-2]) = {Aig^Wg^l AXAigrWg^]} U sub[g,) U subig^) 

We will distinguish between Q-formulas and /^-formulas, which are con- 
junctions and disjunctions, respectively. In the reduced tableau, if a state 
satisfies a conjunction, then it also satisfies its two conjuncts. On the other 
hand, if it satisfies a a disjunction, it will usually satisfy only one of the 
disjunct, leaving the other as "don't care'*. 

Definition 1.2 (a-formula) 

A formula g G sub{'^) is an a-formula if g — g\ t\ gi- 

Definition 1.3 (^-formula) 

A formula g G sub{'(p) is a (3-formula if : 

1- 9 — 9\'^ 92, in which case ki{g) = {g-i} and k2{g) — {^'2}- 
2. g = AlgiWga], in which case ki{g) = {^2} and k2{g) = {gi , AX A[giW g2]} . 
Definition 1.4 (A particle) A set of formulas P is a particle if: 

1. P C sub{ij) 

2. p e P ^ P 

3. ^pGP^p^ P 

4. P does not contain any a-formula nor any jS-formula. 

Definition 1.5 (Implied successor) A formula g is an implied successor 
of a particle P if AXg e P. We denote by imps{P) the set of implied 
successors of P . i.e., imps{P) — {g\AXg € P} 

Note that if P does not include any formula of the form AXg then 
imps{P) — {} . The particle {} means that the state reached has no com- 
mitments to satisfy any of the formulas. Thus, it may be the start of any 
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possible paths. Furthermore, it may simulate any state. We later see that 
the only son of particle {} is the particle {} itself. 

function Remove Jiedandant{S : Set of Particles) : returns Set of Particles 
return the largest set such that {P g 5|VP,- G S, P, (f. P} 



recursive function coverp{B : Set of formulas) returns : Set of particles 
if B is not locally consistent then return {} - no particles contain B 
if there exists some a-formula r = ri A r2 in B 

then return coverp{B — {r} U {ri.r2}) 
if there exists some /^-formula r such that r E B then return 

coveVpiB ~{r}Uki{r)) U cov€rp{B - {r} U k^ir)) 
return {B} - S is a particle 

end function 

Definition 1.6 {SuccessorSp{P)) 

Successorsp{P) — RemaveJR.edandant{coverp{imj)s{P))) . 

We now describe an iterative algorithm PART_TAB that produces the tableau 
structure. 
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Algorithm : PART_TAB 

Sro '■= Remove^Redandant{coverp{{tl;})) 

St := S'-rO 

Mark all particles in St as unprocessed 
For each unprocessed particle P in St do 

S := successor Sp{P): 

For each Q € 5 

Add {P,Q) to Rt; 

Define L{P) = Pn {p\p e AP^} fl {^p\p e AP4,} 
If g^5.; 

Add g to 5^; 

Mark Q as unprocessed; 
end for 

Mark P as processed; 
end for 
end for 

Note that a state is labeled by propositions from AP and by their nega- 
tions. Since a state is a particle, it will never contain both a proposition and 
its negation, but it may contain none of them. 

We now prune the structure we received, such that any particle has at 
least one successor. 
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Algorithm : PRUNE_TAB 

Mark all particles in Sr as unprocessed 
Repeat until all particles in Sr are processed 
For each unprocessed particle P in Sr do 
If P has no successors 
Remove P from 5,- 
Remove any edge going to P from 
Mark the remaining particles in Sr as unprocessed 
Skip 

Mark P as processed; 
end for 
end Repeat 

After activating PART.TAB and PRUNE_TAB we have produced the 

tableau t('0) =< Sr: SrO, Rr, Lr > foT 0. 

Note that the tableau we construct is total. Any particle that has no 
successors is removed. 
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APPENDIX B 

The following is a program listing in VHDL 
describing a tableau that corresponds generally to the 
properties of arbiter 40 listed in Table II. As noted 
hereinabove, however, the listing below is based on a 
simplified model without the non-observable variable 
-robin." In place of the output names ACKO_SPEC and 
ACK1_SPEC shown in Fig. 2, the names ackO_new and 
ackl_new are used in the listing; and reqO and reql in 
the listing correspond respectively to REQO_SPEC and 
REQ1_SPEC. 

library ieee; 

use ieee . std_logic_1164 . all; 

entity full_spec is 
port ( 

rb clock •• in std_ulogic; 



ackO_new 
ackl_new 
reqO 
reql 



in std_ulogic; 
in std_ulogic; 
in std_ulogic; 
in std_ulogic; 



reset ' std_ulogic; 



fails 



: out 

std_ulogic_vector (0 to 5) 



end full_spec; 

architecture rb of full_spec is 

signal not_rb_reset : std_ulogic 



IS999-035 



33 



35519S3 



signal rb_reset : std_ulogic ; 
type rb_enum_type is ( iu_enuin_slash_err , 
ill enum_slastL_z) ; 



5 begin 



p: 

process 
begin 

10 wait until rb_clock' event and rb_clock='l' 

not_rb_reset <= '1'; 
end process; 

rb reset <= reset or (not not_rb_reset ) ; 



f 1 : 

fails (0) <=^ not b21(((((not ackO_new) or (not 

ackl_new) ) ) /= ' 0' ) 
or (rb_reset /= '0') or (rb_clock /= '1')); 
f2 : 

block 

constant n: integer := 4; 
signal v: std_ulogic_vector ( 0 to n-1) := 
"1110"; 

signal v_out : std_ulogic_vector ( 0 to n-1); 

signal vnext: std_ulogic_vector ( 0 to n-1); 

signal ok: std_ulogic := '1'; 
begin 
v_out ( 0 ) <= ' 0 ' ; 
v_out ( 1 ) <= V ( 1 ) and ( ' 1 ' ) ; 

v_out(2) <= v(2) and (((not reqO) and (not 
reql) ) ) ; 
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v_out(3) <= v(3) and ((not ((not ackO_new) and 
(not ackl_new) ) ) ) ; 

vnext(O) <= '0'; 

vnext ( 1 ) <= v_out ( 1 ) ; 
vnext(2) v_out(l); 

vnext (3) <= v_out(2); 



p: 

process 
begin 

wait until rb_clock ' event and rb_clock='l'; 
if rb_reset = '1' then 
V <= "1110"; 
ok <= ' 1 ' ; 

else 

if (not (v(3) and (not ((not ackO_new) 
and (not ackl_new) ) 

) ) ) = ' 0 ' then 

ok ' 0 ' ; 

elsif ok = ' 0 ' then 

ok <= ' 1 ' ; 
end i f ; 



V <= vnext; 
end if; 
end process; 



fails (1) <= not b21 ((ok /= '0') or (rb_reset 
'0') 

or (rb_clock /= '1')); 
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end block; 



f3: 

block 

constant n: integer := 4; 

signal v: std_ulogic_vector ( 0 to n-1) := 
"1110"; 

signal v_o-at : std_ulogic_vector { 0 to n-1); 

signal vnext: std_ulogic_vector ( 0 to n-1); 

signal ok: std_ulogic := '1'; 
begin 
v_out ( 0 ) <= ' 0 ' ; 
v_out (1) <- V ( 1 ) and ( ' 1 ' ) ; 

v_out(2) <= v{2) and ( (reqO and (not ackO_new) 
V out (3) <= v(3) and ((not ackO_new) ) ; 



vnext (0) 
vnext ( 1) 
vnext (2) 
vnext (3) 



' 0' ; 

v_out ( 1 ) ; 
v_out ( 1) ; 
v_out ( 2 ) ; 



p: 

process 
begin 

wait until rb_clock ' event and rb_clock= ' 1 ' ; 
if rb_reset = '1' then 
V <= "1110"; 
ok <= ' 1 ' ; 

else 

if (not {v(3) and (not ackO_new) ) ) 
' 0 ' then 
ok <= ' 0 ' ; 
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elsif ok = ' 0 ' then 

ok <= ' 1' ; 
end if; 

V <= vnext; 
end if; 
end process; 



fails (2) <= not b21 ((ok /- '0') or (rb_reset 
/= '0') 

or (rb_clock /= '1')); 
end block; 

f4 : 

block 

constant n: integer 4; 
signal v: std_ulogic_vector ( 0 to n-1) 
"1110"; 

signal v_out : std_ulogic_vector ( 0 to n-1); 

signal vnext: std_ulogic_vector ( 0 to n-1); 

signal ok: std_-ulogic := '1'; 
begin 
v_out ( 0 ) <- ' 0 ' ; 
v_out ( 1 ) <= V ( 1) and ( ' 1 ' ) ; 

v_out(2) <= v(2) and (((not reqO) and reql) ) ; 
V out (3) <= v(3) and ((not ackl_new) ) ; 



vnext (0) <= '0'; 

vnext (1) <= v_out(l) 

vnext (2) <= v_out (1) 

vnext (3) <= v_out(2) 
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process 
begin 

5 wait until rb_clock; ' event and rb_clock;= ' 1 ' ; 

if rb_reset '1' then 
V <= "1110"; 
ok <= '1' ; 

else 

10 if (not (v(3) and (not ackl_new) ) ) = 

'0' then 
ok <= ' 0 ' ; 
elsif ok = ' 0 ' then 
ok <= '1' ; 
15 end if; 



V <= vnext; 
end if; 
end process; 



fails (3) <- not b21 ((ok /- '0') or (rb_reset 
/= '0') 

or (rb_clock /= '1')); 
end block; 



fS: 

block 

constant n: integer := 4; 
3 0 signal v: std_ulogic_vector ( 0 to n-1) ;= 

"1110"; 

signal v_out : std_ulogic_vector ( 0 to n-1); 
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signal vnext: std_ulogic_vector { 0 to n-1); 

signal ok: std_ulogic := '1'; 
begin 
v_out{0) <= '0'; 

v_out(l) <= v(l) and ('1') ; 

v_out(2) <= v(2) and ( (reql and ackO_new) ) ; 

v__out(3) <= v(3) and ((not ackl_new) ) ; 



vnext ( 0 ) 
vnext ( 1 ) 
vnext (2) 
vnext (3) 



' 0' ; 

v_out ( 1 ) 
v_out ( 1 ) 
v_out (2) 



process 
begin 

wait until rb_clock' event and rb_clock= ' 1 ' ; 
if rb_reset = '1' then 
V <= "1110"; 
ok <= ' 1' ; 

else 

if (not (v(3) and (not ackl_new) ) ) 
' 0 ' then 

ok <= ' 0' ; 
elsif ok = ' 0 ' then 

ok <= ' 1' ; 
end if; 



V <= vnext; 
end if; 
end process; 
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fails (4) <= not b21 ((ok /= '0') or (rb_reset 
/- '0') 

or (rb_clock /= 1 ' ) ) ; 
end block; 



f 6: 

block 

constant n: integer := 4; 
signal v: std_ulogic_vector ( 0 to n-1) := 
"1110"; 

signal v_out : std_ulogic_vector ( 0 to n-1); 

signal vnext : std_ulogic_vector ( 0 to n-1); 

signal ok: std_ulogic := '1'; 
begin 
v_out(0) <= '0'; 
v_out ( 1 ) <= V ( 1 ) and (' 1 ' ) ; 

v__out(2) <= v(2) and ( (reqO and (not reql) ) ) ; 
V out (3) <= v(3) and ((not ack0_new) ) ; 



vnext ( 0 ) 
vnext ( 1 ) 
vnext (2) 
vnext (3) 



' 0' ; 

v_out ( 1) ; 
v_out ( 1) ; 
v_out (2) ; 



p: 

process 
begin 

wait until rb_clock' event and rb_clock='l'; 
if rb_reset = '1' then 
V <= "1110"; 
ok ' 1' ; 
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else 

if (not (v(3) and (not ackO_new) ) ) = 
' 0 ' then 
ok ' 0' ; 

5 elsif ok = ' 0 ' then 

ok <= • 1' ; 
end if; 

V <= vnext; 
10 end if; 

end process; 



fails (5) <= not b21 ((ok /= '0') or (rb_reset 
15 /= '0') 

or (rb_clock /= ' 1 ' ) ) ; 
end block; 

end rb; 



IS999-035 



41 



35519S3 



CLAIMS 

1 1. A method for verification, comprising: 

2 providing an implementation model, which defines 

3 model states of a target system and model transitions 

4 between the model states; 

5 providing a specification of the target system, 

6 comprising properties that the system is expected to 

7 obey; 

8 creating a tableau from the specification, the 

9 tableau defining tableau states with tableau transitions 

10 between the tableau states in accordance with the 

11 properties; and 

12 comparing the tableau transitions to the model 

13 transitions to determine whether a discrepancy exists 

14 therebetween. 

1 2. A method according to claim 1, wherein creating the 

2 tableau comprises defining a finite state machine using a 

3 hardware description language. 

1 3. A method according to claim 2, wherein the 

2 implementation model has model inputs and outputs, and 

3 wherein defining the finite state machine comprises 

4 describing a virtual device having inputs and outputs 

5 corresponding to the model inputs and outputs of the 

6 implementation model. 

1 4. A method according to claim 3, wherein comparing the 

2 transitions comprises performing a reachability analysis 

3 using both the implementation model and the tableau while 

4 providing identical inputs to the inputs of both the 

5 implementation model and the tableau, and verifying that 

6 the outputs are always identical. 
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1 5. A method according to claim 4, wherein performing 

2 the reachability analysis comprises comparing the model 

3 and the tableau automatically using a model checker. 

1 6. A method according to claim 4, wherein performing 

2 the reachability analysis comprises providing evidence of 

3 a tableau transition that is not implemented in the 

4 model. 

1 7, A method according to claim 1, wherein comparing the 

2 tableau transitions comprises associating model 

3 transitions with corresponding tableau transitions. 

1 8. A method according to claim 1, wherein associating 

2 the transitions comprises defining a reachable simulation 

3 preorder relating the model and the tableau. 

1 9. A method according to claim 7, wherein associating 

2 the transitions comprises finding a tableau transition 

3 that is not implemented in the model. 

1 10. A method according to claim 9, wherein finding the 

2 tableau transition that is not implemented in the model 

3 comprises deriving an indication, based on the 

4 unimplemented transition, that the specification is not 

5 complete with respect to the model. 

1 11. A method according to claim 9, wherein finding the 

2 tableau transition that is not implemented in the model 

3 comprises deriving an indication, based on the 

4 unimplemented transition, that a transition of the target 

5 system is missing in the model. 

1 12. A method according to claim 1, and comprising 

2 associating model states with corresponding tableau 

3 states. 
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1 13. A method according to claim 12, wherein associating 

2 the model states with the corresponding tableau states 

3 comprises finding a tableau state that is not implemented 

4 in the model. 

1 14. A method according to claim 13, wherein finding the 

2 tableau state that is not implemented in the model 

3 comprises deriving an indication, based on the 

4 unimplemented state, that the specification is not 

5 complete with respect to the model. 

1 15. A method according to claim 13, wherein finding the 

2 tableau state that is not implemented in the model 

3 comprises deriving an indication, based on the 

4 unimplemented state, that a state of the target system is 

5 missing in the model. 

1 16. A method according to claim 12, wherein associating 

2 the model states with the corresponding tableau states 

3 comprises finding multiple model states corresponding to 

4 a single tableau state. 

1 17. A method according to claim 1, wherein creating the 

2 tableau comprises creating a reduced tableau from which 

3 one or more redundant states have been eliminated. 

1 18. A method according to claim 1, wherein comparing the 

2 transitions comprises verifying that the specification is 

3 a complete and correct description of the implementation 

4 model responsive to the comparison. 

1 19. A verification processor, which is configured to 

2 receive an implementation model, defining model states of 

3 a target system and model transitions between the model 

4 states, and to receive a specification of the target 
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5 system, including properties that the system is expected 

6 to obey, and which is operative to create a tableau from 

7 the specification, the tableau defining tableau states 

8 with tableau transitions between the tableau states in 

9 accordance with the properties, and to compare the 

10 tableau transitions to the model transitions to determine 

11 whether a discrepancy exists therebetween. 

1 20. A processor according to claim 19, which is 

2 operative to perform model checking of the implementation 

3 model. 

1 21. A computer software product for verification of a 

2 specification of a target system, which specification 

3 includes properties that the system is expected to obey, 

4 by comparison with an implementation model, which defines 

5 model states of the target system and model transitions 

6 between the model states, the product comprising a 

7 computer-readable medium having computer program 

8 instructions recorded therein, which instructions, when 

9 read by a computer, cause the computer to create a 

10 tableau from the specification, the tableau defining 

11 tableau states with tableau transitions between the 

12 tableau states in accordance with the properties, and to 

13 compare the tableau transitions to the model transitions 

14 to determine whether a discrepancy exists therebetween. 

1 22. A product according to claim 21, wherein the program 

2 instructions cause the computer to compare the tableau 

3 with the model by running a reachability analysis using 

4 both the implementation model and the tableau while 

5 providing identical inputs to the inputs of both the 

6 implementation model and the tableau, and verifying that 

7 the outputs are always identical. 
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1 23. A product according to claim 22, wherein the 

2 reachability analysis is performed using an automatic 

3 model checker. 

1 24, A product according to claim 21, wherein the 

2 instructions cause the computer to verify that the 

3 specification is a complete description of the 

4 implementation model. 

1 25. A method for verification, comprising: 

2 providing an implementation model, which defines 

3 model states of a target system and model transitions 

4 between the model states; 

5 providing a specification of the target system, 

6 comprising properties that the system is expected to 

7 obey; 

8 creating a tableau from the specification, the 

9 tableau defining tableau states with tableau transitions 

10 between the tableau states in accordance with the 

11 properties; and 

12 comparing the model and the tableau by inputting the 

13 model and the tableau to an automatic model checking 

14 program, 

1 26. A method according to claim 25, wherein creating the 

2 tableau comprises defining a finite state machine using a 

3 hardware description language, 

1 27. A method according to claim 26, wherein the input 

2 model has model inputs and outputs, and wherein defining 

3 the finite state machine comprises describing a virtual 

4 device having inputs and outputs corresponding to the 

5 model inputs and outputs of the implementation model. 
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1 28. A method according to claim 21, wherein comparing 

2 the model and the tableau comprises running the model 

3 checker while providing identical inputs to the inputs of 

4 both the implementation model and the tableau, and 

5 verifying that the outputs are always identical. 

1 29. A method according to claim 25, wherein comparing 

2 the model and the tableau comprises providing evidence of 

3 a transition or state in the tableau that is not 

4 implemented in the model. 

1 30. A method according to claim 29, wherein providing 

2 the evidence comprises providing a counter-example 

3 indicative of the unimplemented transition or state. 

1 31. Model checking apparatus, which is configured to 

2 receive an implementation model, defining model states of 

3 a target system and model transitions between the model 

4 states, and to receive a specification of the target 

5 system, including properties that the system is expected 

6 to obey, and which is operative to create a tableau from 

7 the specification, the tableau defining tableau states 

8 with tableau transitions between the tableau states in 

9 accordance with the properties, and to compare the 

10 tableau to the model by inputting the model and the 

11 tableau to an automatic model checking program. 

1 32. A computer software product for verification of a 

2 specification of a target system, which specification 

3 includes properties that the system is expected to obey, 

4 by comparison with an implementation model, which defines 

5 model states of the target system and model transitions 

6 between the model states, the product comprising a 

7 computer-readable medium having computer program 
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8 instructions recorded therein, which instructions, when 

9 read by a computer, cause the computer to create a 

10 tableau from the specification, the tableau defining 

11 tableau states with tableau transitions between the 

12 tableau states in accordance with the properties, and to 

13 compare the tableau to the model by inputting the model 

14 and the tableau to an automatic model checking program. 
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IDENTIFICATION OF MISSING PROPERTIES IN MODEL CHECKING 



ABSTRACT 

A method for verification includes providing an 
implementation model, which defines model states of a 
target system and model transitions between the model 
states, and providing a specification of the target 
5 system, including properties that the system is expected 
to obey. A tableau is created from the specification, 
the tableau defining tableau states with tableau 
transitions between the tableau states in accordance with 
the properties. The tableau transitions are compared to 
10 the model transitions to determine whether a discrepancy 
exists therebetween. 
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